<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xml:lang="en" xmlns="http://www.w3.org/1999/xhtml">
 <head>
  <meta content="Copyright &copy; 2023 Thales. All Rights Reserved." name="copyright"/>
  <meta content="text/html;charset=utf-8" http-equiv="content-type"/>
  <meta content="text/css" http-equiv="Content-Style-Type"/>
  <title>
   Arcadia Reference - Product Line Definition
  </title>
  <link href="../../scripts/jquery-treeview/jquery.treeview.css" rel="stylesheet"/>
  <script src="../../scripts/jquery-treeview/lib/jquery-1.11.1.js" type="text/javascript">
  </script>
  <script src="../../scripts/jquery-treeview/jquery.treeview.js" type="text/javascript">
  </script>
  <link href="../../css/simpletree.css" rel="stylesheet" type="text/css"/>
  <link href="../../css/content.css" media="screen, projection" rel="stylesheet" title="default" type="text/css"/>
  <style>
   body {}
			.treeview {
				background-color: white ;
			}
	
			.treeview ul{ /*CSS for Simple Tree Menu*/
				background-color: white;
				font-size: 12px;
			}
	
			.treeview li{ /*Style for LI elements in general (excludes an LI that contains sub lists)*/
				background-color: white;
			}
  </style>
 </head>
 <body>
  <img src="../icon/logo_arcadia_small.png" style="float:left;width:50px;height:50px;"/>
  <nav>
   <a href="1a79525b3b624a7094acd0b580842ce6.html#">
    ARCADIA
   </a>
   <a href="1a79525b3b624a7094acd0b580842ce6.html#landscape">
    Engineering Landscape
   </a>
   <a href="1a79525b3b624a7094acd0b580842ce6.html#userGuide">
    User Guide
   </a>
   <a href="1a79525b3b624a7094acd0b580842ce6.html#reference">
    Reference Manual
   </a>
  </nav>
  <p>
   <br/>
  </p>
  <div id="content">
   <img alt="FunctionalChain" src="../icon/FunctionalChain.png" style="float:left; margin-right:10px"/>
   <h1>
    <a href="../ARCADIA/bc963afd94714150845a92dbee4ef686.html">
     Product Line Definition
    </a>
   </h1>
   <p style="margin-top:3px; margin-bottom:3px">
    <span class="elementMetaClass">
     Engineering Process
    </span>
    <p>
    </p>
   </p>
   <em class="elementPath">
    <a href="../ARCADIA/ad8c8a109fa64f039584c15108639254.html">
     Engineering Capabilities
    </a>
    &gt;
    <a href="../ARCADIA/5ee5cfb619964bbab1d5c244cc567caf.html">
     Minimise Development Cost
    </a>
    &gt;
    <a href="../ARCADIA/bc963afd94714150845a92dbee4ef686.html">
     Product Line Definition
    </a>
   </em>
   <p>
    <p>
     <strong>
      Challenge: How&nbsp;to build and justify a product line contents.
     </strong>
    </p>
    <ul>
     <li>
      Integrated approach between market/business analysis, architecture definition and variability engineering
     </li>
     <li>
      Can largely rely on architectural method such as Arcadia
     </li>
    </ul>
    <p>
     Harmonisation of&nbsp;market &amp; business analyses with architecture &amp; design:
    </p>
    <ul>
     <li>
      &lsquo;Operational stakeholders Need Analysis&rsquo; is the place to start collaboration
     </li>
     <li>
      &lsquo;Need vs Solution&rsquo; articulation in architecture &amp; method secures coherency
     </li>
    </ul>
    <p>
     Verification process for variabilities &amp; options:
    </p>
    <ul>
     <li>
      Confront to customer need and solution architecture, value analysis&hellip;
     </li>
     <li>
      to manage complexity of variability (Feature model) and simplify/secure it in coherence with architecture description
     </li>
    </ul>
    <p>
     Benefits of integrated approach:
    </p>
    <ul>
     <li>
      because Feature Model alone&nbsp;is not enough guiding to choose among options
     </li>
     <li>
      Architecture analysis simplifies some variability sources,
     </li>
     <li>
      helps in defining and reducing dependencies between variants,
     </li>
     <li>
      and secures adequacy between variability and architecture,
     </li>
     <li>
      eases and encourages using high level variability(e.g. on op. capabilities),
     </li>
     <li>
      and achitecture model helps and justifies option selection and combinations
     </li>
    </ul>
    <p>
     How to define and check valid architecture configurations?
    </p>
    <ul>
     <li>
      By derivating an architecture model per configuration, and analysing it for consistency, completeness and adequacy to needs &amp; constraints
     </li>
    </ul>
   </p>
   <h2>
    Related Diagrams
   </h2>
   <div>
    <p class="diagram-name" id="_3ZHPkJB3EeqRa_cMzDL6lQ">
     7  Product Line Definition
    </p>
    <p class="diagram">
     <img alt="7  Product Line Definition" src="bc963afd94714150845a92dbee4ef686/_3ZHPkJB3EeqRa_cMzDL6lQ.jpg" usemap="#7  Product Line Definition__3ZHPkJB3EeqRa_cMzDL6lQ_PositionMap"/>
     <br/>
     <br/>
     <map name="7  Product Line Definition__3ZHPkJB3EeqRa_cMzDL6lQ_PositionMap">
      <area alt="487b3ab24b0e40bbb70daded98286d3f" coords="1140,82,1261,143" group="487b3ab24b0e40bbb70daded98286d3f" href="../ARCADIA/487b3ab24b0e40bbb70daded98286d3f.html#id487b3ab2-4b0e-40bb-b70d-aded98286d3f" shape="rect"/>
      <area alt="b273e2e253ef42f0a6d1c63f53b8a3a5" coords="30,80,151,141" group="b273e2e253ef42f0a6d1c63f53b8a3a5" href="../ARCADIA/b273e2e253ef42f0a6d1c63f53b8a3a5.html#idb273e2e2-53ef-42f0-a6d1-c63f53b8a3a5" shape="rect"/>
      <area alt="c354668558fc433fa1124e7b02e6bc7f" coords="260,80,371,141" group="c354668558fc433fa1124e7b02e6bc7f" href="../ARCADIA/c354668558fc433fa1124e7b02e6bc7f.html#idc3546685-58fc-433f-a112-4e7b02e6bc7f" shape="rect"/>
      <area alt="4f8b5a2854014b0fac95b1715b6b0469" coords="480,80,591,141" group="4f8b5a2854014b0fac95b1715b6b0469" href="../ARCADIA/4f8b5a2854014b0fac95b1715b6b0469.html#id4f8b5a28-5401-4b0f-ac95-b1715b6b0469" shape="rect"/>
      <area alt="38c7424f5c11476490db367b0b43bc42" coords="720,82,831,143" group="38c7424f5c11476490db367b0b43bc42" href="../ARCADIA/38c7424f5c11476490db367b0b43bc42.html#id38c7424f-5c11-4764-90db-367b0b43bc42" shape="rect"/>
      <area alt="3bc550c63f304bcf914f5e7a64da9b18" coords="1140,230,1251,291" group="3bc550c63f304bcf914f5e7a64da9b18" href="../ARCADIA/3bc550c63f304bcf914f5e7a64da9b18.html#id3bc550c6-3f30-4bcf-914f-5e7a64da9b18" shape="rect"/>
      <area alt="e5e58f7bc69b418cbd3d0d9a325ee053" coords="700,230,831,291" group="e5e58f7bc69b418cbd3d0d9a325ee053" href="../ARCADIA/e5e58f7bc69b418cbd3d0d9a325ee053.html#ide5e58f7b-c69b-418c-bd3d-0d9a325ee053" shape="rect"/>
      <area alt="bea95df828bb41859edc7fbc49e9f8af" coords="260,230,371,291" group="bea95df828bb41859edc7fbc49e9f8af" href="../ARCADIA/bea95df828bb41859edc7fbc49e9f8af.html#idbea95df8-28bb-4185-9edc-7fbc49e9f8af" shape="rect"/>
      <area alt="d1de805fb6bc4f14831b3413ca0931c2" coords="30,230,151,291" group="d1de805fb6bc4f14831b3413ca0931c2" href="../ARCADIA/d1de805fb6bc4f14831b3413ca0931c2.html#idd1de805f-b6bc-4f14-831b-3413ca0931c2" shape="rect"/>
      <area alt="870e3144de35486382669407f2a609c7" coords="910,230,1021,291" group="870e3144de35486382669407f2a609c7" href="../ARCADIA/870e3144de35486382669407f2a609c7.html#id870e3144-de35-4863-8266-9407f2a609c7" shape="rect"/>
     </map>
    </p>
    <p class="diagram-description">
     <p>
      This figure describes
     </p>
     <p>
      <strong>
       How&nbsp;to build and justify a product line contents.
      </strong>
     </p>
     <ul>
      <li>
       Integrated approach between market/business analysis, architecture definition and variability engineering
      </li>
      <li>
       Can largely rely on architectural method such as Arcadia
      </li>
     </ul>
     <p>
      Harmonisation of&nbsp;market &amp; business analyses with architecture &amp; design:
     </p>
     <ul>
      <li>
       &lsquo;Operational stakeholders Need Analysis&rsquo; is the place to start collaboration
      </li>
      <li>
       &lsquo;Need vs Solution&rsquo; articulation in architecture &amp; method secures coherency
      </li>
     </ul>
     <p>
      Verification process for variabilities &amp; options:
     </p>
     <ul>
      <li>
       Confront to customer need and solution architecture, value analysis&hellip;
      </li>
      <li>
       to manage complexity of variability (Feature model) and simplify/secure it in coherence with architecture description
      </li>
     </ul>
     <p>
      Benefits of integrated approach:
     </p>
     <ul>
      <li>
       because Feature Model alone&nbsp;is not enough guiding to choose among options
      </li>
      <li>
       Architecture analysis simplifies some variability sources,
      </li>
      <li>
       helps in defining and reducing dependencies between variants,
      </li>
      <li>
       and secures adequacy between variability and architecture,
      </li>
      <li>
       eases and encourages using high level variability(e.g. on op. capabilities),
      </li>
      <li>
       and achitecture model helps and justifies option selection and combinations
      </li>
     </ul>
     <p>
      How to define and check valid architecture configurations?
     </p>
     <ul>
      <li>
       By derivating an architecture model per configuration, and analysing it for consistency, completeness and adequacy to needs &amp; constraints
      </li>
     </ul>
     <p>
      For each step of this process, involving an engineering task or activity, the description gives some hints and methological recommendations. These recommendations are complementary with the description of the involved activity per se, in the context of the engineering concern and the process.
     </p>
    </p>
   </div>
   <h2>
    Contribution of each engineering activity to this process
   </h2>
   <table>
    <tr>
     <th>
      Engineering activity
     </th>
     <th>
      Specifics of activity for this process
     </th>
    </tr>
    <tr>
     <td>
      <img alt="PhysicalFunction" src="../icon/PhysicalFunction.gif"/>
      <a href="../ARCADIA/b273e2e253ef42f0a6d1c63f53b8a3a5.html">
       Perform CUSTOMER OPERATIONAL NEED ANALYSIS
      </a>
     </td>
     <td>
      <p>
       During the operational need analysis activity, a market segmentation is elaborated based on classifying and characterizing the stakeholders potentially involved in system use and operation. They are captured as Operational Entities (organizations, systems, etc.) or Operational Actors (human users for example). For each market segment, the expectations of the stakeholders are expressed in terms of Operational Capabilities, Missions, Scenarios, Operational Processes and related Operational Activities.
      </p>
      <p>
       Value characterization for each market segment applies on former elements. It captures end-user value, criticality, and conditions of combination/exclusion, including expected quality of service and non-functional aspects.
      </p>
     </td>
    </tr>
    <tr>
     <td>
      <img alt="PhysicalFunction" src="../icon/PhysicalFunction.gif"/>
      <a href="../ARCADIA/d1de805fb6bc4f14831b3413ca0931c2.html">
       Define operational &amp; Market Segmentation Variabilities
      </a>
     </td>
     <td>
      <p>
       In parallel with the Operational Analysis,
       <span class="inline-comment-marker" data-ref="09b34ac8-921b-4f3b-b38c-efc5dae86f02">
        customer profiles are established to describe each customer segment, collaboratively with marketing and sales teams, according to enterprise product policy.
       </span>
       For each segment and each relevant stakeholder,
       <span class="inline-comment-marker" data-ref="1b11807a-bd14-4e17-b1fb-bebb73e5c7eb">
        jobs, pains and gains are describe
       </span>
       d: Jobs are what customers are trying to get done in their work and in their lives; Pains are anything that annoys the customers before, during and after trying to get a job done; Gains are the outcomes and benefits customers would like.
      </p>
      <p>
       &nbsp;
      </p>
      <p>
       The concepts of the Operational Analysis constitute a great support as jobs can naturally be related to Operational Activities and pains/gains can consist in characterizations of these Activities.&nbsp;
      </p>
      <p>
       &nbsp;
      </p>
      <p>
       <span class="inline-comment-marker" data-ref="f77b845e-90f6-433c-854c-e6b7bbcdc440">
        Operational Analysis and customer profiling favor thorough analyses and understanding of the stakeholders activities and expectations, from which&nbsp;user-level features and options emerge.&nbsp;
       </span>
      </p>
      <p>
       <span class="inline-comment-marker" data-ref="f77b845e-90f6-433c-854c-e6b7bbcdc440">
        This emerging variability tree is captured in a high-level Feature Model that describes firstly orientations and alternatives. Variability analysis may in turn shape the content and structuring of the Operational Capabilities and Activities.
       </span>
      </p>
      <p>
       <span class="inline-comment-marker" data-ref="f77b845e-90f6-433c-854c-e6b7bbcdc440">
        Checks for global consistency of options &amp; alternatives and user profiles should be performed here (e.g. seeking for Activities needed to ensure a capability and missing in a feature, or scenarios in an alternative mentioning activities of another incompatible one, or operational process broken by an optional activity&hellip;)
       </span>
      </p>
     </td>
    </tr>
    <tr>
     <td>
      <img alt="PhysicalFunction" src="../icon/PhysicalFunction.gif"/>
      <a href="../ARCADIA/c354668558fc433fa1124e7b02e6bc7f.html">
       Perform SYSTEM NEED ANALYSIS
      </a>
     </td>
     <td>
      <p>
       The System Need Analysis activity is about identifying and describing the system expected capabilities. Capabilities&nbsp;rigorously capture the ability of the system to render services contributing to the realization of one or several operational capabilities. These capabilities are exemplified with functional chains, scenarios and functions that not only describe how the system is expected to behave, but also help specify non-functional expectations.
      </p>
      <p>
       Following realization links from Operational Analysis, a first orientation of the variability analysis is possible thanks to this functional analysis, taking into account the former market segmentation and users expectations.
       <span class="inline-comment-marker" data-ref="e2af437e-db75-4074-9a1e-b2aeab55af23">
        &nbsp;
       </span>
      </p>
      <p>
       &nbsp;
      </p>
     </td>
    </tr>
    <tr>
     <td>
      <img alt="PhysicalFunction" src="../icon/PhysicalFunction.gif"/>
      <a href="../ARCADIA/bea95df828bb41859edc7fbc49e9f8af.html">
       Define Product specification and commercial Offer variabilities
      </a>
     </td>
     <td>
      <h3 id="IS21Paper-MBSEinaPLEcontext-Valueandvariabilityanalysis">
       <strong>
        <em>
         Value and variability analysis
        </em>
       </strong>
      </h3>
      <p>
       The value analysis approach is similar to Market Analysis and Segmentation. In response to the stakeholder pains and gains, services, gain creators and pain relievers are identified. Services (typically captured as capabilities and functions) describe what the product will offer and what will help stakeholders complete their jobs or reach their objectives. Gain creators emphasize how certain product functionality will help users/customer be more efficient (in terms of time, quality, or effort for example). Pain Relievers will emphasize how certain product functionality will contribute to help users/customer address the difficulties they face.
      </p>
      <p>
       &nbsp;
      </p>
      <p>
       Value analysis strengthens the system need analysis. It grounds the product definition on solid foundations and when combined to the stakeholder profiles, it justifies the creation of a new set of system-level variability features and options that are are captured in a refined version of the Feature Model.
      </p>
      <p>
       This integrated, model-supported approach benefits and simplifies variability analysis in at least three ways:
      </p>
      <ul>
       <li>
        The alignment between system capabilities and the structure of the Feature Model brings both organizational (structuring of engineering responsibilities and activities) and technical advantages (easier consistency checking, easier impact analysis).&nbsp;
       </li>
       <li>
        The modeling effort favors the identification of commonalities, with elements of the functional analysis&nbsp;(capabilities, functional chains, scenarios, and functions) that are transverse to all segments and markets
       </li>
       <li>
        The dependencies between elements of the functional analysis
        <span class="inline-comment-marker" data-ref="b5e8d0d4-7bcb-4b28-9a30-a56ea4c4bd00">
         influence and even simplifies features
        </span>
        . For example, defining one single feature or option on a functional chain instead of several ones on the functions involved in the functional chain is much simpler. In addition, dependencies between features can be deduced from dependencies between elements of the functional analysis.&nbsp;
       </li>
      </ul>
      <h3 id="IS21Paper-MBSEinaPLEcontext-CommercialPortfolioDefinition">
       <strong>
        <em>
         Commercial Portfolio Definition
        </em>
       </strong>
      </h3>
      <p>
       <span class="inline-comment-marker" data-ref="95f28b80-5749-44dc-9d28-d287e6acba1e">
        Based on these functional and value analyses, the Commercial Offer Portfolio can be defined and structured (such as a car range with different equipment and finishing levels and option packs). For this purpose, standard configurations can be built from analysis and characterization of the assets above, each configuration being a selection of appropriate features options or alternatives. These standard configurations constitute the portfolio to be proposed to customers.
        <br/>
        These standard configurations are key in order to simplify the definition of the solution for a given customer: they guide the customer choices according to market segments and towards company preferred capabilities and assets, hence maximizing reuse; they reduce the number of architectures to be evaluated and validated both at definition time and at Integration Verification and validation (IVV) time, etc.
       </span>
      </p>
      <p>
       The same kind of coherency checks between System Need Analysis and&nbsp;Commercial Portfolio Definition has to be performed, as it is&nbsp;supposed to be done at operational level. Coherency with market analysis should also be checked thanks to links with operational analysis.
      </p>
     </td>
    </tr>
    <tr>
     <td>
      <img alt="PhysicalFunction" src="../icon/PhysicalFunction.gif"/>
      <a href="../ARCADIA/4f8b5a2854014b0fac95b1715b6b0469.html">
       Explore Solution Space &amp; Alternatives
      </a>
     </td>
     <td>
      <p>
       The model-based design of the solution architecture follows the same patterns than the ones of Operational and System Need Analyses. Capabilities are exemplified with scenarios and functional chains that describe how the system works and not only what is expected from it. They help specify the exact contribution of each system constituent. The functional behavior of the solution must not only realize the functional analyses defined in Operational and System Analyses, it must also reflect and implement their variabilities: for example, if a functional chain of the system need analysis is associated to a variability feature, its corresponding functional chains in solution architecture must also be associated to it.
      </p>
      <p>
       From a structural point of view, product variability may significantly constrain architecture design: for example, functions that have different variability conditions should be implemented by separate components; similarly, alternative behaviors should yet preserve similar common interfaces, and common core behavior should be implemented by dedicated core components.
      </p>
      <p>
       New variabilities are likely to appear, based on limitations or opportunities in solution, technology, or context, leading to a solution feature model. Links between architecture and feature models are built accordingly.
      </p>
     </td>
    </tr>
    <tr>
     <td>
      <img alt="PhysicalFunction" src="../icon/PhysicalFunction.gif"/>
      <a href="../ARCADIA/38c7424f5c11476490db367b0b43bc42.html">
       Design PHYSICAL ARCHITECTURE
      </a>
     </td>
     <td>
      <p>
       Architecture Variability constraints may deeply influence architecture design (e.g. separating functions or components that have different variability conditions).
      </p>
      <p>
       Architecture can simplify and reduce the number of alternatives and options, notably due to architectural consistency or dependencies for example :
      </p>
      <ul>
       <li>
        Because architecture constraints may lead to group different variabilities, that can be then considered as a whole
       </li>
       <li>
        Because some options are not independent due to architecture constraints
       </li>
       <li>
        Because one model element may group several options, etc.
       </li>
      </ul>
     </td>
    </tr>
    <tr>
     <td>
      <img alt="PhysicalFunction" src="../icon/PhysicalFunction.gif"/>
      <a href="../ARCADIA/e5e58f7bc69b418cbd3d0d9a325ee053.html">
       Ensure consistency between Solution Architecture and product Variability
      </a>
     </td>
     <td>
      <h3>
       <strong>
        <em>
         <span class="inline-comment-marker valid" data-ref="a8b9f0b4-b544-43ab-bf10-75a0ecfbc1c9">
          Consistency checking
         </span>
        </em>
       </strong>
      </h3>
      <p>
       Here again, checking
       <span class="inline-comment-marker" data-ref="62a22e2c-7ced-4b7c-bfb7-e26cb0b17df6">
        coherency and consistency
       </span>
       between architecture, feature model and configurations contents is key,
       <span class="inline-comment-marker" data-ref="4d3fc53c-759e-4afc-9feb-1e7d121b1b40">
        notably:
       </span>
      </p>
      <ul>
       <li>
        Consistency of components breakdown with variability
       </li>
       <li>
        Consistency of function to component allocation with variability and options
       </li>
       <li>
        Identification of dependencies or incompatibilities between features due to architectural concerns
       </li>
       <li>
        Validity of features and configurations in preserving components dependencies, scenarios &amp; functional chains consistency&hellip;
       </li>
       <li>
        Specific work on non-functional properties, quality of service, etc.
       </li>
      </ul>
      <h3>
       <strong>
        <em>
         <span class="inline-comment-marker valid" data-ref="a8b9f0b4-b544-43ab-bf10-75a0ecfbc1c9">
          Variability Implementation and Mastering
         </span>
        </em>
       </strong>
      </h3>
      <p>
       Once architecture and feature models are consistent with each other, the features and configurations definition should be applied to most engineering assets and beyond : requirements, architecture definitions and models, simulations models and scenarios, specialties and disciplines specific assets and models, test means and enabling systems, test campaigns, test cases, and beyond product breakdown structure, development and production means, support means, tooling, etc.
      </p>
     </td>
    </tr>
    <tr>
     <td>
      <img alt="PhysicalFunction" src="../icon/PhysicalFunction.gif"/>
      <a href="../ARCADIA/870e3144de35486382669407f2a609c7.html">
       Define Product Reference Configurations
      </a>
     </td>
     <td>
      <h3 id="IS21Paper-MBSEinaPLEcontext-SolutionVariabilitiesOrientation">
       <strong>
        <em>
         <span class="inline-comment-marker valid" data-ref="df40b18f-7f06-41d7-9392-552d11173db4">
          Solution Variabilities Orientation
         </span>
        </em>
       </strong>
      </h3>
      <p>
       An analysis of the solution architecture can simplify and reduce the number of variability features, notably due to architectural consistency or dependencies. For example, architecture constraints may lead to group different variabilities, that can be then considered as a whole: there is no need to treat them separetely if the same components and functions are required for all of them.
      </p>
      <p>
       <span class="inline-comment-marker" data-ref="95537ec6-0bd0-4116-b760-3f5203863711">
        Design standard configurations
       </span>
       are also defined to implement and refine the former market profiles and portfolio standard configurations, including solution-specific variabilities, and dealing with former architecture-originated constraints and simplification opportunities. Product standard configurations are expected to cover and fit most users needs, by appropriate contents according to users, system need and architecture. So each final, solution-level standard configuration should notably:
      </p>
      <ul>
       <li>
        satisfy a set of users belonging to a segment identified in Operational Analysis
       </li>
       <li>
        be compliant with commercial offer orientations as defined in portfolio and at System Need Analysis level
       </li>
       <li>
        be coherent with designed architecture, for feasibility and efficiency reasons.
       </li>
      </ul>
     </td>
    </tr>
    <tr>
     <td>
      <img alt="PhysicalFunction" src="../icon/PhysicalFunction.gif"/>
      <a href="../ARCADIA/487b3ab24b0e40bbb70daded98286d3f.html">
       Define BUILDING STRATEGY - contracts for development &amp; IVVQ
      </a>
     </td>
     <td>
      <h3 id="IS21Paper-MBSEinaPLEcontext-BuildingStrategy">
       <strong>
        <em>
         <span>
          Building Strategy
         </span>
        </em>
       </strong>
      </h3>
      <p class="MsoBodyText">
       <span>
        Development contract (Specification) of solution components and building blocks must integrate the product variabilities and configurations policy:
        <span class="inline-comment-marker" data-ref="b4a7cdd0-9b3d-41d8-a45d-ebf57f73f369">
         the fact that for the system engineering, a component should be optional, does not necessarily impact the engineering of this component
        </span>
        ; but a component may have to adapt to other components variability (e.g. dealing with optional components missing in some configurations), and it may have to deal with internal functional or non-functional variability, as requested by system engineering.
       </span>
      </p>
      <p class="MsoBodyText">
       <span>
        Integration, verification, validation procedures should test variability points and check major standard configurations as such.
       </span>
      </p>
      <h3 class="MsoBodyText" id="IS21Paper-MBSEinaPLEcontext-BuildingBlocksVariabilityManagement">
       <span>
        &nbsp;
       </span>
       <strong style="text-align: right;">
        <em>
         <span>
          Building Blocks Variability Management
         </span>
        </em>
       </strong>
      </h3>
      <p class="MsoBodyText">
       The solution architecture might rely on certain building blocks that can have their own product variabilities and policies. Variability at both levels must be compatible and harmonized accordingly. The result of this necessarily collaborative work should be part of the development contract for each building block.
      </p>
     </td>
    </tr>
    <tr>
     <td>
      <img alt="PhysicalFunction" src="../icon/PhysicalFunction.gif"/>
      <a href="../ARCADIA/3bc550c63f304bcf914f5e7a64da9b18.html">
       Setup environment for the Domain engineering
      </a>
     </td>
     <td>
      <p>
       Once architecture and feature models are consistent with each other, the features and configurations definition should be applied to most engineering assets and beyond : requirements, architecture definitions and models, simulations models and scenarios, specialties and disciplines specific assets and models, test means and enabling systems, test campaigns, test cases, and beyond product breakdown structure, development and production means, support means, tooling, etc.
      </p>
     </td>
    </tr>
   </table>
   <h2>
    Diagrams displaying "Product Line Definition"
   </h2>
   <ul>
    <li>
     <a href="../ARCADIA/bc963afd94714150845a92dbee4ef686.html#_3ZHPkJB3EeqRa_cMzDL6lQ">
      7 - Product Line Definition*
     </a>
    </li>
   </ul>
  </div>
 </body>
</html>
